对话黄东旭、关涛、李远策：数据引擎，One Size Fits All 真的能实现么？
以下内容来自于InfoQ《再谈数据架构》系列直播，云器联合创始人& CTO 关涛出席。
今天，数据平台是企业的必选项。长期以来，企业在选择数据平台架构时，多倾向于针对流处理和批处理两大场景分别部署两套方案。近年来，一体化数据融合平台的概念逐渐受到关注，行业开始尝试在同一个架构中同时处理不同类型的数据，简化数据平台技术栈。那么企业真的可以使用一套解决方案应对所有场景吗？一体化数据平台有哪些主流选项？Lambda 与 Kappa 架构各有哪些优势和不足？企业该如何选择适合自己的解决方案？
针对上述问题，InfoQ 联合云器科技策划了《极客有约》特别版——《再谈数据架构》系列直播的第三期。本期节目，我们邀请到了 PingCAP 联合创始人兼 CTO 黄东旭、云器科技联合创始人 & CTO 关涛以及快手科技数据架构中心总架构师李远策，畅谈以下话题：
从需求视角看，当前用户需要怎样的数据平台？
AI 火热的今天，数据平台如何更好地支持 AI 能力？
数据融合平台的发展趋势？
从需求视角看，
当前用户需要怎样的数据平台？
关涛：不同企业需求不同。如果面向未来思考这个问题，第一，当前选型数据平台，需要做到 Data+AI 一体化，要能支持半 / 非结构化存储，能支持 SQL 和 AI 的运算，避免建成即落伍。第二，考虑总 TCO（总持有成本）最低，是否投入人力自建或者采用 SaaS 服务。最后一点，平台是否足够简单，让非技术背景的用户也能使用，AI 技术也在帮助这一点。
黄东旭：我觉得未来像 HTAP 的数据库能够进一步把 Kappa 架构的实时性和数据的新鲜程度再推进一步。我一直相信大数据会向数据库这个方向走，它会慢慢把很多传统的大数据的东西渐渐统一。
李远策：企业选择技术架构时，首先要理清需求和关注的指标，还要考虑到备选产品背后公司的影响力、经营状态，这样才更容易招到合适的人来做事情。偏中小型的公司还要考虑产品的可用性，尽量采用比较简洁的架构。
Q
InfoQ：大数据领域有着超过 20 年的发展历史。从企业视角来看，今天大数据已经是必选项，那么对企业而言，我们需要怎样的数据平台呢？
关涛：从企业的视角看，大数据现在是默认的必选项，在这个前提下可以抽象出三个挑战（同时也是选型的一些考虑）：
第一，是平台总持有成本。每个企业几乎都在做海量数据，为此需要付出硬件成本、软件成本与人力运维成本。降本是一个非常高优先级的话题。
第二，对比数据库系统和大数据系统，大数据系统相对就复杂一些。以 Hadoop 的系统为例，一个相对完备的 Hadoop 系统大概七八个组件拼接在一起，对于使用和维护，这是很大的技术挑战。
第三，是这个领域发展很快，这就需要持续追赶和迭代。例如最近就在讨论怎样利用 AI 提升数据平台的能力。客户一方面会考虑新技术能否用起来，一方面会考虑平台怎么能扩展支持这些能力。
从企业视角，选择数据平台时第一要考虑平台能否存储和管理更全域的数据，例如非结构化、非流化的数据；第二是它能否支持 SQL 以外的多种计算态势，第三就是平台能否有效实现降本增效。最后一点，平台是否足够简单，让非技术背景的用户也能使用。
黄东旭：补充两点。从历史上看，大数据的行业变化趋势一定程度上也能反映用户的需求变迁。2000 年前后，谷歌发现他要处理的数据量远大于传统的单机数据库分库分表技术能够承载的极限，而且这个系统也难以扩展，只能用多台小机器连在一起变成一个大的分布式系统来做数据处理。所以我觉得 Big data 技术之所以难用是有历史根源的，一开始它就不是奔着通用系统去设计。后来我们看到，几乎所有的数据系统开始又重新支持 SQL 或更易用、更标准化的 API，通用性及易用性越来越像数据库，这是第一个趋势。
第二个趋势就是从 MapReduce 到 Streaming System 再到现在的 HTAP，大家一直在追求越来越高的实时性。现在很多实时的报表甚至对于数据的一致性和事务性都提出了要求，我觉得这也是另外一个趋势。
李远策：我站在一个企业用户的视角来谈一谈企业使用过程中会遇到哪些痛点、挑战。数据处理流程包括数据采集、数据加工和数据分析三大环节，其中数据加工环节的时间消耗是比较大的，超过了 50% 的比重。数据加工环节面临不少挑战，比如流批两种数据生产模式对应的两套计算引擎有各自的学习和维护成本，这是第一点。
第二点是大数据架构经常处理多种数据来源的数据，又会使用多种计算引擎，这给数据的质量和计算结果的一致性也带来了很大的挑战。数据质量在企业内部是一个比较重要的问题，它往往比数据延迟影响更大，而且具有一些隐藏性和传递性。一旦出问题，数据质量的影响面是不可控的，所以我认为数据质量也是当前数据处理的一个非常大的痛点，需要从数据加工的规范以及全链路的数据质量监控、计算引擎的算子语义的一致性等多个层面上来做好保障工作。
数据的治理和规范化也是一个非常大的挑战。数据治理对数据质量、数据安全、成本控制以及找数等多个方面有很多很关键的作用，所以做好数据治理需要体系化的建设；数据的管理规范，比如元数据管理等，也可能是比较大的挑战。
下一个问题，我们怎么样定义一个好的数据引擎？有几个方面，第一个是成本，对于计算引擎来讲成本等价于算力，对于存储引擎来讲成本控制主要来源于数据的副本数。第二点是数据质量，包括引擎的稳定性、计算结果准确性，还有存储数据的可靠性等方面。第三点是效率，包括两个方面，一是交互式分析的查询延迟，二是数据开发效率。最后一个是数据的安全性，这一点在企业里也是非常关键的。
Q
InfoQ：现在我们能看到越来越多的企业选择将架构转变成一体化的 Kappa 架构，背后都有哪些考虑点？
李远策：大数据架构经历了一个架构演化的过程，早期是离线批数架构，后来过渡到了 Lambda 架构。Lambda 架构相对于离线数据架构来讲主要引入了实时阶段链路，提升了数据处理的时效性，可以更实时地看到过程中的数据计算结果；同时也为了保障数据最终一致性，它需要把最终的离线计算的链路结果进行覆盖。其实 Lambda 架构是比较复杂的，资源消耗也比较快。
Kappa 架构解决了 Lambda 架构的一些缺陷，可以理解成一种 Lambda 架构简化版。比如说 Kappa 架构只依赖于实时计算链路来做数据计算，如果需要数据重计算或者新增计算指标，它需要对历史数据进行回放计算。Kappa 架构最大的优势是架构比较简单，需要依赖的数据引擎较少。
黄东旭：早期的大数据处理平台，其流计算部分没办法支持批量或者很大的离线计算，基本没有数据存储和加工能力，所以就有了 Lambda 架构。
Kappa 架构诞生的背景是现在的这些新一代的基础设施配上比较高性能的 OLAP 数据库基本上也能做到流批一体。有了流批一体这样的新的数据库和流处理系统以后，技术的进步让 Kappa 架构变得更简单，它其实是历史的必然。
虽然 Kappa 现在是比较前沿的方向，但我仍然觉得这是一个中间状态。Kappa 架构仍然没有办法很好地去处理更实时的场景。我觉得未来可能像 HTAP 的数据库能够进一步把 Kappa 架构的实时性和数据的新鲜程度再推进一步。HTAP 相当于又可以把前面数据服务的那块 DB 归纳进来，所以我一直相信大数据会向数据库这个方向走，它会慢慢把很多传统的大数据的东西渐渐统一。
关涛：换个视角来看，一体化平台都能解决哪些问题呢？第一个问题是用户界面侧的语法和语义的统一。第二点是多系统的组合带来了元数据不统一、数据存储不统一的问题。第三点，因为三套系统各自独立需要分别管理，且需要很多数据同步，开发维护成本很高。
所以一体化架构第一是统一语言、统一开发体验，简化用户开发过程；第二是统一存储、统一计算；第三是你能不能比较灵活地在这几个点上做切换。数据新鲜度、延时和成本构成了数据处理不可能三角，如前面所说，你很难把这三点都保证住，但一体化系统能比较容易地在这三个点之间做转换。
Q
InfoQ：不同的企业面临不同的业务场景，那么针对各种需求背景，企业采用哪一种模式是最合适的呢？
李远策：企业选择技术架构时，首先要理清需求和关注的指标，还要考虑到备选产品背后公司的影响力、经营状态，这样才更容易招到合适的人来做事情。偏中小型的公司还要考虑产品的可用性，尽量采用比较简洁的架构。Kappa 结构就是比较简洁，遇到的问题相对比较收敛，比较容易管理。技术选型还要有一些前瞻性，防止数据架构的频繁迭代。不过目前在企业内部，Lamdba 架构因为其灵活性的优势采用度还是很高，Kappa 的技术还有很大迭代空间。
关涛：虽然不同企业有不同选择，但大方向还是一致的。数据领域从数据库到数据分析再到 AI，前半部分的场景基本已经固定了，而这些领域中都在向着更简单、更一体化的方向升级。这里 HTAP、流批一体、湖仓一体都是整合模式，好处就是开发、运维更简单，成本更低。
Lambda 是当前很多企业做数据分析的主流架构，企业需要低成本的批处理，同时又需要非常快的实时报表，就用 Lambda 架构搭一个。而 Kappa 就是个思想，本质是希望能在这些地方上做统一，是技术发展趋势。面向未来，企业选择一个一体化架构或者向这个方向演进是明确的。
AI 火热的今天，
数据平台如何更好地支持 AI 能力？
黄东旭：第一点，个人或企业的个性化数据必须有一个存储服务，能够很轻易地让 AI 去访问、读取。第二点，现在的 AI 就像一个黑盒，很难验证它给你的答案是不是 100% 准确的。但数据技术可以给 AI 一个补充。
关涛：AI 极大扩展了数据处理的能力，可以说 AI 是整个数据领域发展的第三级推进火箭。LLM 比较新发展快，架构并不固定，我建议平台架构总体保持扩展性，考虑到数据分析和 AI 两方面的需求就好了。很多企业的平台架构可以等待 AI 技术更成熟一点再跟进，让子弹再飞一会。
李远策：AI 在数据分析领域会越来越多地发挥重要作用。为此，数据平台要用好 AI 就要通过上云来降低成本。
Q
InfoQ：AI 是当下的大热主题。数据平台天然就非常适合做 AI 的用武之地，那么整体来看，数据平台该如何更好地拥抱 AI 呢？
黄东旭：对于数据平台来说，第一个趋势，个人或企业的个性化数据必须有一个存储服务，能够很轻易地让 AI 去访问、读取。第二点，现在的 AI 就像一个黑盒，很难验证它给你的答案是不是 100% 准确的。但数据技术可以给 AI 一个补充。比如我们可以直接去问 LLM 一个事实性的问题，但我要求它的回答并不是告诉我结论，而是帮我生成 SQL，用这个 SQL 去查询包含事实信息的数据库。因为我确认数据库的数据是真实的，所以这样就规避掉了 AI 瞎编答案的问题。这就对数据平台提出一个新的需求，要能很好地支持大语言模型给你生成的稀奇古怪的 SQL。
结合这两个需求，你会发现数据应用的场景越来越广，这样就必须得思考怎么以更低的成本把这些数据存储和处理起来。AI 的时代数据量会更大，访问方式会更加灵活，但显然用现在的这些思路去解决，成本就太高了。我觉得要规模化地降低存储成本，一条路就是上云，第二就是减少冗余，一体化还有一个好处就是降低了数据的冗余度。第三还是要靠存储、计算引擎的突破。大多数数据应用还是符合八二原则，80% 的数据可能价值比较低，20% 的数据可能是比较热的。这对弹性计算的能力要求就会更高，需要对弹性计算友好的计算引擎，加上能够智能地决定数据冷热分布的存储引擎。
关涛：AI 极大扩展了数据处理的能力，可以说 AI 是整个数据领域发展的第三级推进火箭，前面第一级是数据库技术，第二级是大数据，第三级是 AI。AI 领域还是变化迭代非常快的领域，数据平台要如何承接它也是一个挑战。
我的建议，第一是保持平台的架构扩展性，比如要考虑怎么存非结构化的数据。第二要考虑数据分析 +AI，SQL 表达和 AI 两方面的需求。以前可能就是 SQL 引擎分析数据，以后一定会有另外一个 AI 引擎可以用，这对架构的开放性要求很高。以前做数仓，存储和计算放在一起没有问题，但现在你得考虑存储计算一定要分离开，而且要保证可能是 m 对 n 的映射才行。第三点，如果你不是特别面向大语言模型或者 AI 向前演进的企业，而是更偏用户的状态，可以让子弹再飞一会儿，你只要保证架构扩展就好了，让这些技术再迭代一段时间，当它形成一定的 Pattern 后再跟进，避免架构频繁调整。
李远策：一个很重要的观点是说自然语言是最好的。我先用自然语言描述问题，之后生成一个 SQL，再跑一个 SQL 把结果取出来。甚至比如说你画出这条曲线之后，曲线可能有一些波动，AI 能帮你做一些归因。所以 AI 在数据分析领域可能会越来越多地发挥重要作用。
第二点，AI 在数据平台应用就伴随着上云、降成本。为什么上云能够降成本？我觉得有三个点，一是存算分离，因为云就有存算分离这个特性。第二是数据的冷热，冷热数据可以采用分级存储，成本自然就降下来。还有就是弹性，可以采用波峰波谷的方式去使用云计算，从而降低成本。
Q
InfoQ：大模型时代，向量数据库也是比较热门的主题。为什么向量数据库热度迅速攀升，它到底解决了什么问题？
李远策：一是大模型现在的实时性还是没那么高，没法及时感知新鲜的数据。第二是大模型在回答私有化的问题时，如果直接使用私有数据会存在安全和隐私方面的问题。向量数据库靠一些 embedding 和相似性计算的方式，可以把更实时和更私有化的数据通过 embedding 得到一些向量存在数据库里，然后经过相似性的搜索，给大模型提供数据的时候会带一些 hint 的信息过去，让大模型能够做一些辅助性检查，这是向量数据库在大模型方面的应用点。
黄旭东：向量数据库是能够提供多维度、模糊查询以及聚类这样特殊查询方式的一种数据库。传统数据库要去查某条数据，可能就像电子表格一样，我知道它的 ID 然后查出来；但是向量数据库查询可能像一个地图一样，我就画一个圈，你告诉我这个地方有什么东西。
为什么向量数据库突然在 LLM 这个领域里边火了呢？因为大模型这边训练完了以后，你要在对外提供服务的时候，有一个环节去做上下文的存储。我做一个对话之类的交互，可能这些上下文要作为这个模型的短期记忆，要有一个存储。
第二就是做事实校验，比如说我把很多事实放到向量数据库里，大模型在回复答案的时候，先要在这个数据库里确认一下事实性。
但你可以发现这两种应用都是在模型对外服务的时候使用，但我觉得这个热度不会持续太久。因为无论图数据库还是向量数据库，它应该属于对现有的数据库框架的一种补充。只要把向量数据库思考成现有数据上的一个特殊索引即可。未来主流数据库可能都会有这些特性去支持大模型的相关应用场景。
关涛：我认为向量数据库是一个中间状态，最终要么被LLM融合，要么被数据平台融合。可以设想如果大模型持续进化，把向量数据库的能力都内置了，向量数据库可能就没落了；如果大模型还是很需要向量数据库，它可能会被整合进主流的数据框架里，变成数据平台、数据引擎里的一个外置索引，而不是那么独立的一套系统。所以我认为向量数据库最终不太会以独立平台 / 系统的方式存在。
数据融合平台的发展趋势
关涛：数据分析领域会更加一体化，Lamdba 架构会被替换。Data 与 AI 会进一步融合。最后，平台会更普惠化、民主化。哪个平台最普惠 / 最简单，能让最多的人用起来，它最终会赢得市场。
黄东旭：大数据的未来一定在云上；实时场景会向 OLTP 这边去靠；Serverless 可能是降本新思路。
李远策：未来的数据架构要继续往统一化演进，会有越来越多的整合型数据产品出来。
Q
InfoQ：数据融合平台下一步的发展趋势是怎样的？各位老师怎么去看它接下来的一些趋势？
关涛：第一是结构化数据分析这个领域会更加一体化，更融合、更简单，从 Lambda 到 Kappa 转型会是一个大方向，未来一段时间会有一系列的企业在这方面向前做突破和迭代。
第二是面向持续变化的 AI 领域，针对数据和 AI 的融合趋势，数据平台要做好准备，提升扩展性，考虑分析型的计算、存储以及非结构化的数据与处理能力，让 AI 的引擎能更好地消费这些数据。
最后，数据平台会越来越简单易用，普惠化、民主化。而不是纯粹的性能竞争。哪个平台最普惠 / 最简单，能让最多的人用起来，它最终会赢的市场。
黄东旭：第一，大数据的未来一定是在云上，包括公有云、混合云等等。更智能的存储引擎、更弹性的计算框架都要构建在云原生技术上，下一步的技术演进会跟云贴得更近。第二点，实时的场景开始越来越向 OLTP 这边去靠。所以有可能会在传统的大数据技术栈中出现一个新的层，这个层可能过去叫 Reverse ETL，也可能叫 Data Serving 或者数据湖中间的某个部分，但我觉得这一层会慢慢地清晰，也是 HTAP 这个场景会发光发热的地方。这一层会慢慢地跟 OLTP 结合，统一一部分实时计算的框架，可能会有更加简单易用的一套数据技术模式，这个模式会以 HTAP、Database 为中心。第三个趋势是 Serverless，Serverless 的很多技术理念用在大数据的处理之上，可能是降成本的新思路。
李远策：未来的数据架构还是要往统一化演进，包括但不局限于流体的计算引擎、统一化的分析引擎，还包括一些在离线混合调度的调度系统，这都是统一化的演化思路。在不久的未来，可能会有越来越多的这种整合型的数据产品出来。
Q
InfoQ：7 月 20 号云器科技是有一个新产品的发布会的，关涛老师方便透露一下吗？
关涛：谢谢主持人。云器科技是成立了一年半的数据平台服务提供商，我们的主打的技术口号是多云和一体化，希望给用户提供全托管的企业级的极致简单的数据平台，我们能同时支持数据和 AI 的负载。
我们在 7 月 20 号会举办首次产品发布会，主题是 “Single Engine · All Data”，如果大家希望关注我们，搜索云器科技就能找到我们的网站和公众号。7 月 20 号，欢迎大家来听我们的发布会。云器是向一体化、SaaS 且多元化的方向演进的，发布会上我们会分享一个 Kappa 架构的最佳实践，然后展示一个数据与 AI 的融合平台 Demo ，以及客户最佳实践，最后尝试对融合 AI 的数据平台会有怎样的效果给出答案。
7 月 20 日，云器科技将首次对外举办新品发布会。云器首创以“Single-Engine”为核心理念的湖仓平台，目前已经完成了数亿元融资！为什么云器可以在当下的市场环境中获得投资方和企业客户的青睐？点击“阅读原文”立刻报名发布会一探究竟！